Method for enabling hierarchical architecture of device management gateways

ABSTRACT

In the field of telecommunications technology, a method for enabling Hierarchical Architecture of device management gateways is applicable to a remote management system having a server and multiple devices that are connected through one or more gateways in multi-level Hierarchical Architecture of Gateways, with a tree structure. More specifically, the method enables a new functionality required for the OMA-DM Gateway MO (GwMO): support for Hierarchical Architecture of Gateways.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority benefit of Application No. 10 2014003580 0, filed Feb. 14, 2014, in the Brazilian Intellectual PropertyOffice, the disclosure of which is incorporated herein by reference.

BACKGROUND

1. Field

The following description relates to the field of telecommunicationstechnology and is applicable to remote management system including aserver and multiple devices connected through one or more gateways in amulti-level Hierarchical Architecture of Gateways, with a treestructure. More specifically, the following description describes amethod that enables a new functionality for the Open MobileAlliance—Device Management (OMA-DM) Gateway MO (GwMO): support forHierarchical Architecture of Gateways.

2. Description of the Related Art

Gateway MO V1.0 [GwMO_TS_V10] introduced the concept of DM-Gateway(Device Management Gateway): an entity that facilitates the interactionbetween a management server and a management client, at least one ofwhich runs OMA-DM, in situations where it is not possible for directinteraction and without help between the management server andmanagement client. The documents cited in the reference section areincorporated herein by reference in its entirety.

GwMO V1.0 [GwMO_TS_V10] achieved several advantages when compared to thetraditional architecture involving only the DM Server and DM Client andalleviated the DM Server in managing each End Device individually.Thanks to GwMO V1.0, the DM Gateway is able to manage the End Devicesbehind it, on behalf of the Server.

The following functionalities are covered by GwMO V1.0:

Many End Devices can be organized and managed together as a specificDevice Group.

DM commands originated by the Server may be distributed to multiple EndDevices that are attached to the Gateway, known as “Command Fanout”. TheServer sends management commands to the Gateway and the Gateway forwardsthe commands to one or many End Devices that were pre-grouped into aspecific Device Group.

After a “Command Fanout” execution, the collection of the responses ofmultiple End Devices attached to the Gateway are grouped into a singleresponse is sent back to the server, and is known as “ResponseAggregation”. After the DM Gateway receives the responses sent by theEnd Device(s), the Gateway may notify the Server about the commandcompletion status, or it may send the aggregated response of thecommand, from multiple End Devices, to the DM Server.

The DM Gateway is able to distribute software images to End Devicesassociated to that Gateway on behalf of the Server. The Server candeliver the image to the Gateway and the Gateway distributes that imageto many End Devices specified by a Device Group.

However, GwMO V1.0 [GwMO_TS_V10], with just one DM Gateway level betweenthe server and client (FIG. 1), presents some limitations in terms offlexibility and scalability.

The GwMO V1.1 Requirement Document (RD) [GwMO_RD_V11] has introduced thedefinition and the requirements for a multi-level architecture calledHierarchical Architecture. A Hierarchical Architecture refers to as amulti-level tree structure composed of a DM Server, DM Gateways, and EndDevices. A DM server is located at the top of the tree. End Devices arelocated at the leaves of the branches. DM Gateways are cascaded inbranches between a DM Server and End Devices. Hierarchical Architectureaddresses large networks with a great number of End Devices, in ascalable way.

In Hierarchical Architecture topology, defined by GwMO V1.1 RD, it ispossible that a parent DM Gateway may be associated to one or more childDM Gateways, in addition to the regular End Devices previously definedin GwMO V1.0.

The introduction of Hierarchical Architecture will add scalability andflexibility to the previous version GwMO V1.0 as follows:

Scalability: The maximum number of supported End Devices is no longerlimited to the capacity of one DM Gateway connection, in order tosupport larger networks as M2M (Machine-to-Machine Communication)networks such as Power-Grids involving thousands or millions of devices.For example, in a tree-like Hierarchical Architecture with 3 levels ofGateways, where each one could manage 50 connections, up to 2551(1+50+50̂2) DM Gateways would be able to manage up to 125 thousand EndDevices (50̂3) in behalf of one single DM Server.

Flexibility: more convenient management topologies may be designed basedon geographic, functional, or organizational criteria. Example: Gatewaysmay be dedicated to specific locations (e.g. building, building floor,block, office), specific functions (e.g. energy consumption metering,security, cooling-heating systems) or organization (department,division, branches).

In order to support the Hierarchical Architecture, GwMO V1.1 RequirementDocument (RD) [GwMO_RD_V11] has defined the requirements for GwMO to beable to manage child Gateways, in addition to the regular End Devices asdefined in V1.0:

-   -   Ability to configure specific Connect-Disconnect Alerts for        child DM Gateways.    -   Ability to configure specific report Alerts for Child DM        Gateways.    -   Ability to configure specific Images provisioning for Child DM        Gateways.    -   Ability to configure specific groups for Child DM Gateways, for        “Command Fanout” to child DM Gateways and “Response Aggregation”        from child DM Gateways.

The GwMO V1.0 Architecture Document (AD) has previously presented theinterface between the DM Gateway and its associated End Devices. Alignedwith the HA requirements, the GwMO V1.1 Architecture Document (AD)[GwMO_AD_V11] has extended the interface between DM Gateway-End Deviceinto a new relationship and interface between Parent Gateway-ChildGateway. Due to these differences, a DM Gateway now needs to know whichkind of devices it is associated to, in its immediate lower level:either an End Device or a Child DM Gateway, in order to invoke/exposethe proper interface.

In order to comply with the requirements according to [GwMO_RD_V11] andwith the proposed architecture design according to [GwMO_AD_V11], thereis a need to differentiate in the Device Inventory which types ofdevices a DM Gateway is associated to, in the immediate lower-level:

An End Device.

A Child DM Gateway.

That differentiation, leveraged on previously existing GwMO V1.0objects, will enable the requirements and architectural aspects for HAraised above, as will be described below in detail.

The prior art presents some solutions that aim to meet the requirementsand architecture to support Hierarchical Architecture of Gateways.

The patent document WO2011021865, titled: TECHNIQUES FOR CONTROLLINGGATEWAY FUNCTIONALITY TO SUPPORT DEVICE MANAGEMENT IN A COMMUNICATIONSYSTEM, by Samsung Electronics, published on Feb. 24, 2011, presentstechniques and algorithms for controlling gateway functionality in orderto support Device Management (OMA-DM), in a communication systemincluding a DM server, a device and just one DM Gateway in-between. Thedocument WO2011021865 includes many management aspects which wereincorporated in OMA-DM GwMO V1.0, which specifies a flat,non-hierarchical topology with just one level of gateway. It differsfrom the present disclosure, which addresses a multi-level, tree-like,Hierarchical Architecture of Gateways, object of next version underdevelopment, the GwMO V1.1, which extends V1.0 in a more flexible andscalable way. Moreover, the present disclosure provides a method and themeans to enable and realize the Hierarchical Architecture, leveraging onfunctionalities available in GwMO V1.0.

The patent document US2012059924, titled METHOD AND APPARATUS FORPERFORMING DEVICE MANAGEMENT THROUGH A GATEWAY DEVICE AND DEVICEMANAGEMENT SERVER, by Huawei, published on Mar. 8, 2012, is also basedon OMA-DM and a system including a DM server, a device and a DM-Gatewayin-between. More specifically, the document US2012059924 proposes amethod for the DM Server to send a DM notification through the DMGateway. The document US2012059924 covers a specific aspect of Devicemanagement in a flat, non-hierarchical topology with just one level ofgateway. It differs from the present disclosure, which addresses amulti-level, tree-like, Hierarchical Architecture of Gateways, and itproposes a method to realize and to enable the Hierarchical Architecturerequirements and architecture design.

The patent document WO2011122816, titled: TECHNIQUES FOR MANAGINGDEVICES NOT DIRECTLY ACCESSIBLE TO DEVICE MANAGEMENT SERVER, by SamsungElectronics, published on Oct. 6, 2011, is also based on OMA-DM and on aflat, non-hierarchical, one-level Gateway topology, including a DMServer, a device, and a DM Gateway in-between. It addresses a specificissue related to handling a change in the device address. Conversely,the present disclosure addresses a multi-level, tree-like, HierarchicalArchitecture of Gateways and proposes a method to realize theHierarchical Architecture requirements and architecture design,leveraging on functionalities available in GwMO V1.0.

The patent document US2013130673 titled: METHOD, DEVICE AND SYSTEM FORMANAGEMENT DEVICE, by Huawei, published on May 23, 2013, is also basedon OMA-DM and on a flat, non-hierarchical, one-level Gateway topology,including a DM Server, a device, and just one DM gateway in-between. Themethod is related to the configuration and handling of a UniformResource Locators (URLs) at the WAN side as an identifier for theGateway at the LAN side. It differs from the present disclosure, whichaddresses a multi-level structure, tree-like, Hierarchical Architectureof Gateways, and proposes a method to realize and to enable theHierarchical Architecture requirements and architecture design.

The patent document WO2012174987, titled TERMINAL MANAGEMENT METHOD ANDDEVICE, by Huawei, published on Dec. 27, 2012, is also based on OMA-DMand on a flat, non-hierarchical, one-level Gateway topology, including aDM server, a device, and just one DM Gateway in-between. It addressesthe aspects of the batch management of devices by a gateway, similar tothe device grouping, fanout command, and response aggregation embodiedin GwMO V1.0. It differs from the present disclosure, which addresses amulti-level, tree-like, Hierarchical Architecture of Gateways andproposes a method to realize and to enable the Hierarchical Architecturerequirements and architecture design.

The patent document US2013294285, titled METHOD FOR MANAGING A RemotelySENSOR NETWORK TOPOLOGY AND GATEWAY, by Huawei, published on Nov. 7,2013, is also based on OMA-DM and on a flat, non-hierarchical, one-levelGateway topology including a DM server, a device—called “sensor” in thedocument US2013294285—and just one DM Gateway in-between. It addresseshow a new device is discovered and notifies its connection to thegateway, similar to the Alert handling mechanism embodied in GwMO V1.0,in Device Info MO. The Device info MO is used to maintain informationabout the handling of different types of End Devices by DM Gateway,based on specified device groups. The document US2013294285 differs fromthe present disclosure, which addresses a multi-level, tree-like,Hierarchical Architecture of Gateways, and proposes a method to realizeand to enable the Hierarchical Architecture requirements andarchitecture design.

The patent document EP1365557A2 titled: DEVICE-SHARING SYSTEM, DEVICEADMINISTRATION TERMINAL, GATEWAY TERMINAL, AND METHOD FOR PROVIDING ADEVICE-SHARING SERVICE, by Seiko Epson, published on Nov. 26, 2003,addresses a home gateway interacting with one or more other homegateways for managing devices, such as printers or scanners through theinternet but, differently than the present disclosure, those gatewaysare not organized in a Hierarchical, multi-level, tree-likeArchitecture, where a parent gateway can manage one or more childGateways, for increased flexibility and scalability.

SUMMARY

Additional aspects and/or advantages will be set forth in part in thedescription which follows and, in part, will be apparent from thedescription, or may be learned by practice of the invention.

The following description relates to the telecommunication field oftechnology and to the remote management systems composed of a serverconnected to multiple devices through gateways in a multi-levelHierarchical Architecture.

Without loss of generality, the present disclosure focuses on oneembodiment where the management protocol among the management Server,Gateways and the End Device is Open Mobile Alliance Device Management[OMA-DM], open standard for device management. More specifically, it isbased on an OMA-DM area, the GwMO the V1.0 (Gateway Management ObjectV1.0) [GwMO_TS_V10] and on the DM Gateway functionality introduced byGwMO.

Leveraging on previously existing functionality in GwMO V1.0, the methodproposed in the present disclosure enables the Hierarchical Architecturefunctionality as foreseen in GwMO V1.1 Requirements and Architecture, byintroducing a new node in Inventory MO, which is resident in the DMGateway, for every device Record entry, the ComponentType node which isable to differentiate which type of components are directly connected toa specific DM Gateway, in the immediate lower level: an End Devicecomponent or Child DM Gateway component. At the same time, this approachis flexible enough to distinguish different classes of End Devices ofdifferent classes and Child Gateways, if required.

By allowing this differentiation the introduced ComponentType node ofthe present disclosure is able to leverage on existing functionality inorder to enable the new Hierarchical Architecture requirements specifiedin GwMO V1.1 Requirements Document (RD) [GwMO_RD_V11] and the newGateway-Gateway interfaces defined for Hierarchical Architecture in GwMOV1.1 Architecture Document (AD) [GwMO_AD_V11]:

-   -   Ability to manage, via DM Commands, End Devices and/or Child DM        Gateways via one or more intermediate DM Gateways in a tree        branch.    -   Ability to configure specific Connect-Disconnect Alerts for        Child DM Gateways.    -   Ability to configure specific report DM Alerts for Child DM        Gateways.    -   Ability to configure specific Software Images provisioning for        child DM Gateways.    -   Ability to configure specific groups for child DM Gateways,        required for Command Fanout and Response Aggregation from child        DM Gateways.

BRIEF DESCRIPTION OF THE DRAWINGS

The objectives and advantages of the present disclosure will becomeapparent from the following detailed description of an exemplary andnon-limitative embodiment from the following figures, wherein:

FIG. 1 shows GatewayMO V1.0 (prior art) topology, with just one level ofDM Gateway between the DM Server and the End Devices—flat structure.

FIG. 2 shows GatewayMO V1.1 which is Hierarchical Architecture tree-liketopology containing multiple levels of DM Gateway between the DM Serverand the End Devices. In HA, a DM Gateway can be directly associated tomany child DM Gateways and/or many regular End Devices, in its immediatelower level.

FIG. 3 shows the Architecture Design (AD) for GwMO V1.0, in thisarchitecture a GwMO component may only be associated with a GwMO Clientcomponent, so there is just one type of interface: the DM Gateway-EndDevice Interface 311.

FIG. 4 presents Architecture Design (AD) for GwMO V1.1—HierarchicalArchitecture—In this architecture a GwMO component may be associated toa GwMO client component or to a child GwMO component, so there are twotypes of interface that must be differentiated: DM Gateway-End Deviceinterface 411 and DM Gateway-DM Gateway interface 412.

FIG. 5 presents the Inventory MO—Including the new node ComponentType toenable Hierarchical Architecture.

FIG. 6 presents Gateway Config MO.

FIG. 7 presents Fanout MO as also part of GwMO MD and resides in DMgateway component.

DETAILED DESCRIPTION

Reference will now be made in detail to the embodiments, examples ofwhich are illustrated in the accompanying drawings, wherein likereference numerals refer to the like elements throughout. Theembodiments are described below to explain the present disclosure byreferring to the figures.

As discussed above, Hierarchical Architecture of DM Gateways (HA)proposed in GwMO V1.1 is able to increase the scalability andflexibility on the previous version GwMO V1.0 [GwMO_TS_V10]. Thus, thepresent disclosure provides a method to enable hierarchical architecturefor DM gateways V1.1. This disclosure introduces a new nodeComponentType in the GwMO V1.0 Device Management tree [DM_TND] anddescribes how ComponentType is able to realize HA by leveragingpreviously existing GwMO V1.0 functionality.

In order to support the Hierarchical Architecture, the followingrequirements have been raised in GwMO V1.1, for the following areas:

HLF—High Level Functional;

DI—Device Inventory;

Group—Device Group;

DCIS—Device Configuration & Images Storage.

TABLE 1 GwMO V1.1 Requirements for Hierarchical Architecture LabelDescription 1. GwMO- DM Server SHALL be able to manage an End HLF-008Device via one or more DM Gateways in a tree branch. 2. GwMO- DM ServerSHALL be able to manage a DM HLF-009 Gateway via one or more other DMGateways in a tree branch. 3. GwMO- DM Server SHALL be able to query aparent DM DI-006 Gateway to obtain specified information of a Child DMGateway, 4. GwMO- DM Server SHALL be able to query a parent DM DI-007Gateway to obtain summarized information pertaining to all Child DMGateways 5. GwMO- A parent DM gateway SHALL provide status, DI-008attached or detached, of the registered Child DM Gateways. 6. GwMO- Aparent DM Gateway SHALL be able to inform DI-009 the DM Server about thenewly registered Child DM Gateways. 7. GwMO- DM Server SHALL be able toconfigure a parent DI-010 DM Gateway to either inform or not the DMserver of newly registered Child DM Gateways. 8. GwMO- DM Server SHALLbe able to manage device Group-002 groups, composed of End Devicesand/or Child DM Gateways. 9. GwMO- GwMO Enabler SHALL support theability to store DCIS-004 data from the DM Server on the DM Gateway (forexample, Delivery Package for SCOMO) for local retrieval by End Devicesand/or Child DM Gateways. 10. GwMO- GwMO Enabler SHALL provide anoptimized and DCIS-005 configurable mechanism to store data on a DMGateway (for example, Delivery Packages for SCOMO), if the data are thesame for End Devices and/or Child DM Gateways. 11. GwMO- GwMO EnablerSHALL allow the DM Server to DCIS-006 configure whether the data (forexample, Delivery Packages to SCOMO) can be stored on a DM Gateway forlocal recovery by End Devices and/or Child DM Gateways.

Architecture Document (AD) GwMO V1.0, shown in FIG. 3, previouslydescribes just one interface: the DM Gateway—End Device Interface 311.So, there were no reasons for differentiating interfaces in V1.0, sincejust one type of component was associated to DM Gateway 302, the EndDevice component 303.

Aligned with the HA requirements in Table 1, the GwMO V1.1 ArchitectureDocument (AD) [GwMO_AD_V11], shown in FIG. 4, has extended the interfacebetween DM Gateway—End Device 411 into a new relationship and interfacebetween Parent Gateway—Child Gateway 412.

Due to these differences, a DM Gateway now needs to know which kind ofdevices it is associated with, in its immediate lower level: either anEnd Device 404 or a Child DM Gateway 403, in order to invoke/expose theproper interface.

In GwMO, the “Inventory MO”, shown in FIG. 5, is used to maintain a listof devices in the network that are managed through the DM Gateway. InGwMO, each End Device entry and its related information are storedinside the Records sub-tree 501.

That Inventory MO is updated when the DM Gateway becomes aware of a newEnd Device in the network or the DM Gateway becomes aware that apreviously subtending End Device is no longer present in the network.That must be extended to Child DM Gateways in HA, besides the EndDevices. In those cases, the Records entries 502 are inserted, updated,or removed by the GwMO Enabler.

In order to meet the above requirements [GwMO_RD_V11] and architecture[GwMO_AD_V11] for HA, there is a need to differentiate the DeviceInventory entries regarding which type of device a DM Gateway isassociated to, in the immediate lower-level:

-   -   An End Device.    -   A Child DM Gateway.

I—Defining new node ComponentType to differentiate the type of deviceassociated to a DM Gateway

The present disclosure proposes a simple approach to introduce a newComponentType leaf node 504 to be added under every Inventory Recordsentry 502, and aligned with the sibling node DeviceID 503, which containthe public identifier Device, as follows:

<x>/Inventory/Records/<x>/ComponentType

Min. Access Status Tree Occurence Format Types Optional ZeroOrOne intGet

If Hierarchical Architecture is supported, the value of this leaf nodeindicates the type of GwMO component directly associated with this DMGateway:

Value Meaning Description 0 End Device An End Device is directlyassociated to this DM Gateway 1 DM Gateway A child DM Gateway isdirectly associated to this DM Gateway >=2 Reserved for Reserved. futureuse

The value of this node MAY be used to support DM Gateway featuresconfiguration and Device Group in Section 6.2 Gateway Config MO. If thisnode is absent, it is assumed by default that ComponentType is an EndDevice (i.e., value 0).

This new leaf node is defined as an optional node, assuming defaultvalue=0 (ie, End Device) when it is absent, backward compatible withGwMO V1.0. It was also defined as Integer type, rather than a Boolean,so it makes room for defining different types of End Devices ordifferent types of DM Gateways, for example a Zigbee gateway or aBluetooth gateway.

The present disclosure will also demonstrate how the differentiation byComponentType on the devices directly connected to the DM Gateway, inthe immediate lower-level (either an End Device or a Child Gateway),leveraged by previously existing functionality available in GwMO V1.0[GwMO_TS_V10] can enable the HA requirements described in Table

II—Defining a DeviceGroup which will use ComponentType as a groupingcriteria to create specific groups for child DM Gateways and End Devices

In GwMO, the “Gateway Config MO”, shown in FIG. 6, is used to maintaininformation regarding the handling of different types of End Devices byDM Gateway, based on specified Device Groups.

The information includes the required configuration for: commandfanouts, bootstrapping, report alerts, and authentication.

A key point is how DM Gateways can be grouped. Once a DM server and DMGateway identify the group of child DM Gateways properly, they canproperly handle Alerts, Image Fanout, Command Fanout, and ResponseAggregation in the same way as GwMO V1.0.

GwMO V1.0 has previously provided a flexible mechanism to define a groupof Devices, associating a GroupID 601 to a criteria 602, as follows:

<x>/DevGroup/<x>/GroupID

Min. Access Status Occurence Format Types Required One Chr Get, NoReplace

The value of this node specifies the device group identifier. This valuemust be unique within the Management Tree of the DM Gateway. The valueof this node must be set by the DM Gateway.

The DM Gateway should follow some naming conventions for device groupsto ensure that the device group identifier does not clash with any EndDevice identifier.

<x>/DevGroup/<x>/Condition/OtherCriteria

Min. Access Status Occurrence Format Types Required ZeroOrOne Chr Get,Replace

The value of this leaf node is the condition expression that the DMserver wants the End Device to fulfill. The value of this node is set bythe DM Server.

The expression is defined using the following ABNF syntax:

  Expression = Condition *(( “I” / “&” ) Condition) Condition = CondStr/ “(“ CondStr ”)” CondStr = URI ( “=” / “>” / “< ” / “!=” ) Value  ;Definition of URI is as per the TND spec Value = ValueStr / “(“ ValueStr”)” / \“ ValueStr \” ValueStr = 1*ValueChar ValueChar = ALPHA / DIGIT /“+” / “_” / “.” / “ ”

An example of the value of this node is:

   (./A/B/Software1/VERSION = 1.20 |./A/B/Software1/VERSION < 1.20) &./A/DevDetail/DevType=Smartphone.

This node is mutually exclusive with the

<x>/DevGroup/<x>/Condition/DevTypeCriteria node

By using this flexible mechanism, we may create a specific GroupIDvalue, which represents a group of child DM Gateways and a criteriabased on the new node ComponentType. Example:

   • <x>/DevGroup/<x>/GroupID 601 =“Gateways”    •<x>/DevGroup/<x>/Condition/OtherCriteria 602 =<x>/Inventory/Records/<x>/ComponentType=2 (i.e. DM Gateway)

Or even combining ComponentType with other Inventory MO fields:

   • <x>/DevGroup/<x>/GroupID 601 =“Smartphone_GW” •<x>/Inventory/Records/<x>/ComponentType 602 = 2 (i.e., DMGateway)&<x>/Inventory/Records/<x>/DevType =“smartphone”.

III—Using defined GroupType for performing Command Fanout and ResponseAggregation with Gateways in HA

In GwMO, the “fanout MO”, shown in FIG. 7, is used to maintaininformation about the movement of fanout DM command and aggregationresponse.

Once a Device Group is defined, it is possible for DM server, forexample, to issue fanout commands 702 to many child DM Gateways at thesame time, if they belong to the same group as well as aggregateresponses to be returned as single responses back to the DM Server. Thatmay be accomplished by setting the TargetRef 701 node below with thevalue of the DevGroup/GroupID previously defined 601.

Fanout/<x>/TargetRef

Min. Access Status Occurrence Format Types Required One Chr Get, Replace

The value of this leaf node specifies the intended target of the DMcommands stored in the DMCommands' node. Depending upon the value of theTargetRefType′ node, the DM Gateway will either issue the DM commands tothe targeted End Device specified by the DeviceID node in the DeviceInventory MO, or it will issue the DM commands to a device groupspecified by a GroupId node in the Gateway Config MO.

That enables the following group management requirements using commandFanout and response aggregation:

In GwMO-Group-002, DM Server shall be able to manage device groups,composed of End Devices and/or Child DM Gateways.

Once a gateway group is defined, it is possible to DM Server issuemanagement commands to query information about many gatewayssimultaneously:

In GwMO-DI-007, DM Server shall be able to query a parent Gateway DM toobtain summarized information pertaining to all child DM Gateways.

IV—Commanding Fanout with Gateway Groups to distribute specific SWimages for Gateways in HA

Based on the same command Fanout mechanism, DM Server is also able todeliver specific images for child DM Gateways, once GroupID is properlydefined.

This enables the following requirement for group provisioning:

In GwMO-DCIS-005, GwMO Enabler shall provide an optimized andconfigurable mechanism to store data on a DM Gateway if the data are thesame for End Devices and/or Child DM Gateways.

V—Configuring different Alerts from Child DM Gateways or End Devices inHA to be reported to DM server

In GwMO, the “Gateway Config MO”, shown in FIG. 6, also maintain theconfigurations about which alerts should be forwarded to DM Server basedon GroupID the device belongs to.

In order to configure alerts for specific Groups of Child DM Gateways,the following functionality is available:

<x>/Config/Alert/<x>

Min. Access Status Occurrence Format Types Required ZeroOrMore node Get

This placeholder node groups the configuration parameters for thereporting of Generic Alerts based on some criteria (e.g., alert type,device type, or device group). This node must contain the DEVTYPE childnode or GroupID child node, but not both.

<x>/Config/Alert/<x>/GroupID

Min. Access Status Occurrence Format Types Required ZeroOrMore chr Get

The value of this leaf node specifies the GroupID, which is specified inthe DevGroup sub-tree of this MO.

This node is mutually exclusive with its sibling node DevType.

By properly configuring Alerts with different End Device groups andChild DM Gateways groups, setting properly the GroupID 603, DM gatewaynode will be able to generate different AlertsTypes 604 for the SMServer.

This enables the following requirements for Alerts:

In GwMO-DI-008, a parent DM Gateway shall provide status, attached ordetached, of the registered child DM Gateways. The attached/detachedalert is provided by 301 (GwMO-2).

In GwMO-DI-009, a parent DM Gateway shall be able to inform the DMserver about the newly registered child DM Gateways—new gateway registeralert provided by 301 (GwMO-2).

VI—Managing MD devices Gateways and Terminals in HA

According to the requirements, GwMO V1.1 Architecture Document (AD)[GwMO_AD_V11], shown in FIG. 4, has extended the previously existinginterface between DM Gateway-End Device 411 into a new relationshipbetween Parent DM Gateway—Child DM Gateway 412. Thanks to theintroduction of new ComponentType node, a DM Gateway will be able todefine which kind of devices it is associated to, in its immediate lowerlevel, either an End Device or a Child Gateway, in order toinvoke/expose the correct interface.

ComponentType=“End Device”: DM Gateway must use the interface 411 (DMGateway-End Device):

-   -   Invoke the interface GwMO-3: for example, to execute DM Commands        in the End Device.    -   Expose the interface GwMO-4: for example, to receive alerts from        End Device.

ComponentType=“Child DM Gateway”: DM Gateway must use interface 412 (DMGateway—DM Gateway):

-   -   Invoke interface GwMO-1: for example, to execute DM commands on        Child DM Gateway.    -   Expose the GwMO-2 interface: for example, to receive alerts from        Child DM Gateways.

That enables the below requirements related to DM commands to bedelivered across Gw-Gw and Gw-End Devices interfaces along the HA,including reading values, writing values, and executing ofscripts/commands on specific nodes residing inside Gateways or EndDevices, as follows:

In GwMO-HLF-008, DM Server shall be able to manage an End Device via oneor more DM gateways in a tree branch. Using of 412 (GwMO-1) for routingcommands between Gw-Gw and 411 (GwMO-3) for the Gateway to command toEnd Device.

In GwMO-HLF-009, DM Server shall be able to manage a DM Gateway via oneor more other DM Gateways in a tree branch.—412 (GwMO-1) for routingcommands between Gw-Gw in HA tree and delivering the command to thetarget DM Gateway.

In GwMO-DI-006, if GwMO Enabler supports [GwMO-HLF-007], then a DMServer shall be able to query a parent DM Gateway to obtain specificinformation of a child DM Gateway.—using 412 (GwMO-1) for a readcommand.

In GwMO-DI-010, DM Server shall be able to configure a parent DM Gatewayto either inform or not inform the DM Server of newly registered childDM Gateways—configuration using 412 (GwMO-1) for a write command.

In GwMO-DCIS-004, GwMO Enabler shall support the ability to store datafrom the DM Server on the DM Gateway, for local retrieval by End Devicesand/or Child DM Gateways.—use interface 411 (GwMO-3) to write imagesfrom DM Gateway into the End Devices).

In GwMO-DCIS-006, Enabler shall allow the DM Server to configure whetherthe data can be stored on a DM Gateway for local retrieval by EndDevices and/or Child DM Gateways.—use interface 412 (GwMO-1) for a writecommand to set that configuration.

The above-described embodiments may be recorded in computer-readablemedia including program instructions to implement various operationsembodied by a computer. The media may also include, alone or incombination with the program instructions, data files, data structures,and the like. The program instructions recorded on the media may bethose specially designed and constructed for the purposes ofembodiments, or they may be of the kind well-known and available tothose having skill in the computer software arts. Examples ofcomputer-readable media include magnetic media such as hard disks,floppy disks, and magnetic tape; optical media such as CD ROM disks andDVDs; magneto-optical media such as optical disks; and hardware devicesthat are specially configured to store and perform program instructions,such as read-only memory (ROM), random access memory (RAM), flashmemory, and the like. The computer-readable media may also be adistributed network, so that the program instructions are stored andexecuted in a distributed fashion. The program instructions may beexecuted by one or more processors. The computer-readable media may alsobe embodied in at least one application specific integrated circuit(ASIC) or Field Programmable Gate Array (FPGA), which executes(processes like a processor) program instructions. Examples of programinstructions include both machine code, such as produced by a compiler,and files containing higher level code that may be executed by thecomputer using an interpreter. The above-described devices may beconfigured to act as one or more software modules in order to performthe operations of the above-described embodiments, or vice versa.

Although the present disclosure has been described in connection withcertain preferred embodiments, it should be understood that it is notintended to limit the disclosure to those particular embodiments.Rather, it is intended to cover all alternatives, modifications andpossible equivalents within the spirit and scope of the invention asdefined by the appended claims.

What is claimed is:
 1. A method for enabling Hierarchical Architectureof device management gateways characterized by differentiating what typeof device is associated with a DM Gateway in its immediate lower level,either an End Device or Child DM Gateway, by introducing a new leaf nodein the GwMO Device Tree [DM_TND], the “Component Type” or ComponentTypenode (504), said new node being added to each entry in the GatewayInventory Records (502), and will be aligned with the sibling nodeDeviceID (503), which contains the public identifier of the device. 2.The method for enabling Hierarchical Architecture of device managementgateways, according to claim 1, characterized by the management protocolbetween Server, Gateways and End Device being the Open Mobile AllianceDevice Management [OMA-DM].
 3. The method for enabling HierarchicalArchitecture of device management gateways, according to claim 1,characterized by being applied or extended to other standards andprotocols for management of device and M2M (Machine to Machinecommunication).
 4. The method for enabling Hierarchical Architecture ofdevice management gateways, according to claim 1, characterized by a newresident node being defined in DM Gateway responsible for thedifferentiation of what type of component is associated with a DMGateway, which is part of a Hierarchical Architecture at its next lowestlevel, wherein said ComponentType additional node can assume differentvalues for “End Device”, “Child DM Gateway” or “Restricted”.
 5. Themethod for enabling Hierarchical Architecture of device managementgateways, according to claim 1, characterized by said ComponentTypeadditional node being defined as an optional node, assuming the defaultvalue.
 6. The method for enabling Hierarchical Architecture of devicemanagement gateways, according to claim 1, characterized by saidComponentType additional node being defined as “End Device” when he isabsent.
 7. The method for enabling Hierarchical Architecture of devicemanagement gateways, according to claim 1, characterized by saidComponentType additional node being set as a node of type Integerinstead of type Boolean, and integer values including “Reserved” inorder to open space for the definition of different types of End Deviceor different types of DM gateways when necessary.
 8. The method forenabling Hierarchical Architecture of device management gateways,according to claim 7, characterized by non-OMA_DM Gateways, as well asnon-OMA_DM End Devices being connected as leaves on the HA, beingtreated as simple End Devices with the DM Gateway, to which they areassociated operating in Adaptive Mode (“Adaptation Mode”).
 9. The methodfor enabling Hierarchical Architecture of device management gateways,according to claim 1, characterized by creating groups of specificdevices (601) for End Devices and child DM Gateways, according to theCriteria node (602), based on ComponentType, or combination betweenComponentType and other Inventory Records entry nodes.
 10. The methodfor enabling Hierarchical Architecture of device management gateways,according to claim 1, characterized by enabling the HierarchicalArchitecture for the “Group” and “Device Inventory” (DI) [GwMO_RD_V11]requirements, which are related to “Fanouts of DM Commands” and“Aggregation response” with DM Gateways in Hierarchical Architecturethrough the use of predefined groups of specific devices (601) for EndDevices and Child DM Gateways, wherein DM Server is able to issue thecommand fanout (702) to many Child DM Gateways at the same time, if theybelong to the same group as well as the aggregation responses to bereturned as only one reply message to the DM Server.
 11. The method forenabling Hierarchical Architecture of device management gateways,according to claim 10, characterized by being obtained by writing thevalue of the predetermined DevGroup (601) on the TargetRef node (701).12. The method for enabling Hierarchical Architecture of devicemanagement gateways, according to claim 1, characterized by, onceDevGroups are suitably defined, allowing a DM command issued by the DMServer can be propagated cascade down along many levels of thehierarchical architecture tree, and across several intermediate DMGateways, by recursive application of the “command fanout” mechanismalong the several levels of the HA.
 13. The method for enablingHierarchical Architecture of device management gateways, according toclaim 1, characterized by the command response being sent back to the DMserver, while this response is cascaded up along many levels of the HAby recursive application of the “aggregation response” mechanism alongmany levels of the HA.
 14. The method for enabling HierarchicalArchitecture of device management gateways, according to claim 1,characterized by supplying and delivering specific images or softwarepackages for many child DM Gateways while using the “fanout of DMcommands” mechanism of, since the GroupID (601) for child DM Gateways isproperly defined.
 15. The method for enabling Hierarchical Architectureof device management gateways, according to claim 1, characterized bythe hierarchical architecture enabling for “Device Inventory” (DI)requirements [GwMO_RD_V11] related to handling different DM Alerts withGateways in Hierarchical Architecture using specific predefined devicesGroups (601) for End Devices and Child DM Gateways by DM Server, receivespecific Alerts from Child DM Gateways, depending on the groups createdbased on ComponentType node.
 16. The method for enabling HierarchicalArchitecture of device management gateways, according to claim 1,characterized by configuring specific Alerts for different End Devicegroups and child DM Gateways groups, achieved by setting properly theGroupID node (603), DM Gateway is able to send different Types of DMAlerts specified in Alertstypes (604) for DM Server for differentGroupIDs.
 17. The method for enabling Hierarchical Architecture ofdevice management gateways, according to claim 1, characterized by,while said MD Alerts can be used to update the Inventory fields(Inventory/Records) of DM Gateway, including said ComponentType node,depending on the type of alert received, these alerts update theinventory information at different levels of DM Gateways, as itpropagates up in the HA architecture up towards the DM Server.
 18. Themethod for enabling Hierarchical Architecture of device managementgateways, according to claim 1, characterized by supporting theHierarchical Architecture, in which a DM Gateway must use differentinterfaces (411 or 412), depending on whether it is associated with anEnd Device or a child DM Gateway, respectively, in said DM Gateway isable to make use of said ComponentType field associated with the devicerelated to invoke/expose the correct interface.